home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98b.txt / 000144_icon-group-sender _Wed Jul 22 13:51:48 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  6KB
  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.8.8/8.8.7) with SMTP id NAA20647
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 22 Jul 1998 13:51:48 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA23494; Wed, 22 Jul 1998 13:51:32 -0700
  7. From: pygmy@eskimo.com (Frank Sergeant)
  8. To: icon-group@baskerville.CS.Arizona.EDU
  9. Subject: Re: using Icon for database application
  10. Date: Wed, 22 Jul 1998 15:03:02 -0500
  11. Reply-To: frank.sergeant@pobox.com
  12. Message-Id: <2Vkt1Yv1uQST084yn@eskimo.com>
  13. Lines: 126
  14. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  15. Status: RO
  16. Content-Length: 5611
  17.  
  18. Oh, I've been moving slowly.  I think I got too excited
  19. seeing the native W95 menus and buttons working and
  20. unjustifiably thought everything else would work out
  21. also.  I overlooked the text entry fields, the
  22. picklists, and so forth.  TextDialog() as well as VIB
  23. seem useless to me at the moment.  Perhaps I could dive
  24. into the Icon source code and modify TextDialog() to
  25. work the way I want.  Ditto for implementing native
  26. text entry fields etc based upon the current interface
  27. to native buttons.  However, from the brief glance I
  28. gave the code a few weeks ago I think I just do not
  29. want to take on what may be such a large and possibly
  30. fruitless task.  I believe Clint has confirmed that
  31. winicon does not have a built-in method of calling
  32. external C routines, so that makes adding other native
  33. W95 widgets (and sockets) more difficult.
  34.  
  35. I have been almost ready to give up Icon for this
  36. project (but glad to keep it available for plain text
  37. processing).
  38.  
  39. However, I see two possibilities that remain for using
  40. winicon.  The first is to write my own widgets using
  41. the built-in Icon graphics routines.  That is, instead
  42. of trying to call native W95 widgets, I just "draw"
  43. them on the screen myself, position the cursor
  44. explicitly, catch each keystroke, etc. etc.  This could
  45. well be easier than trying to figure out the interface
  46. to Windows and the Icon source code.  This might be a
  47. reasonable approach.  It still leaves the question of
  48. socket access.  I think I could write a tiny program in
  49. C that handles the socket connection and communicates
  50. with the Icon process via a shared disk file.  This
  51. would seem to be an acceptable work around until
  52. winicon gets socket support.
  53.  
  54. The other possibility is to decide to let web browsers
  55. handle the user interface.  Then, I'm back to being
  56. able to use Icon in purely text mode.  It can generate
  57. the HTML to send via the web server to the browser.  My
  58. book on JavaScript arrived yesterday.  Using an older
  59. MSIE browser to view some of the book's examples makes
  60. me think this just might work.  JavaScript seems to let
  61. me catch the keystroke events (I really want my users
  62. to be able to do with keystrokes everything they can
  63. now do with keystrokes!) and generate my own 'submit'
  64. requests, rather than requiring the user to click on
  65. 'submit'.  Anyway, the examples didn't look too bad.
  66. I've downloaded a newer Netscape which I'll try to
  67. install later today and then take another look at the
  68. JavaScript examples.  The buttons, picklists, text
  69. entry fields, and so forth looked pretty good under
  70. MSIE.  The fonts were ugly, but perhaps they could be
  71. changed.  The browser's own tool bar and menu bar still
  72. took up far too much screen real estate but I think
  73. (from the JavaScript book) that I can create a
  74. full-screen window.
  75.  
  76. In my depression (following my earlier elation) over
  77. Icon, I've reconsidered VO (Computer Assoicates' Visual
  78. Objects), Delphi, Python with Tk, Python with a COM
  79. interface to Delphi, Object REXX, a raw C engine that
  80. reads the widget information from a text file (which
  81. Icon could then write), etc.
  82.  
  83. Object REXX is definitely out.  The examples I tried
  84. were too slow even on a P166 with 48MB RAM and a copy
  85. of the Object REXX run-time would need to be purchased
  86. for each machine in each customer's office.  To hell
  87. with that.  I probably could learn VO or Delphi
  88. eventually.  VO looks better but I found periodic
  89. slow-downs when browsing over the network that seem
  90. unacceptable (and unexplainable).  The Python COM
  91. Delphi might produce very pretty screens but is a whole
  92. 'nuther learning experience I'd rather avoid.  I may
  93. decide that Python with Tk is fast enough after all.
  94. At least Python has sockets built in (as I understand
  95. it).  I don't really want to build my own GUI engine in
  96. raw C.  The graphapp C GUI library looks good so that's
  97. still a possibility.  JPython (Python written in Java,
  98. and so having access to the Java GUI widgets) is
  99. another possibility.
  100.  
  101. I guess I'll try to push further with JavaScript/Icon
  102. and possibly the Python/Tk and see what happens.
  103.  
  104. > I suppose what I'm finding odd for me is that I usually
  105. > use icon because of the way it handles text, not
  106. > because of its graphics capabilities.
  107.  
  108. So, we have a terrible inversion.  (Well, perhaps only
  109. I have it).  Would should be the difficult/important
  110. part of the application (the actual data processing) is
  111. very easy.  Would should be the trivial part (put up the
  112. GUI) is a nightmare of endless "gotchas".
  113.  
  114. > You might also find the zero notation useful (end of
  115. > record, line, whatever) if you have data kept in a list
  116. > of varying length.
  117.  
  118.      Yes, I love that in Icon.  Python is zero-based
  119. and so cannot use 0 as the end of list indicator.
  120. Other than that, Python's array/list/dictionary
  121. handling looks very much like Icon's (to my untrained
  122. eye).  Of course, since my Clipper code is already
  123. one-based, it would be less error prone to move to
  124. one-based Icon rather than to zero-based Python.
  125.  
  126. > Anyway, I was glad to see your post to the icon-group.
  127. > I think we should see some work soon on the problem out
  128. > of Arizona and Texas. My understanding is that the
  129. > Arizona group did most of the work on vib.
  130.  
  131. Disclaimer: This post is meant mostly to express my
  132. current state of mind (it is possible this state of
  133. mind was affected somewhat by working until very late
  134. last night and then awakening to customer problems
  135. early this morning).  No offense is meant to the
  136. hard working, good natured, helpful Icon and Python
  137. people.  All suggestions, comments, criticisms
  138. cheerfully received either by posting or direct email.
  139.  
  140.  
  141.   -- Frank
  142.   frank.sergeant@pobox.com
  143.  
  144.